The present invention is related to simulation of circuit designs. More particularly, the present invention is directed to a method and system for simulation of mixed-language circuit designs.
Circuits have become so complex that it is no longer possible to simply design and build a circuit and expect it to work correctly the first time. Designers use various types of programming languages, such as hardware description languages (e.g., Verilog and VHDL) and object-oriented languages (e.g., C/C++/SystemC and Java), to model new circuit designs by hierarchically defining functional components of a circuit.
The model is then simulated on a computer to see if the design will work as intended. Any problems can be corrected in the model, and the correction verified in simulation. Simulation dynamically verifies a design by monitoring behaviors of the model with respect to simulation test benches.
Designs are often described using the concept of modules. For example, a functional component in a circuit may be described using one or more modules. A module is a syntactic construct in Verilog that is used to define a block. However, the term module is also used loosely by those skilled in the art to designate analogous constructs in other programming languages even though different concepts may be implied. For example, the VHDL equivalent of a module is an architecture and the C++ equivalent of a module is a class. Since a module is generally parameterized, it may be instantiated one or more times in a circuit design. In addition, modules may instantiate other modules.
Each type of programming language has its strengths and weaknesses when used to model an electronic circuit. For example, hardware description languages are excellent solutions for designs that are bound at the register-transfer level and have no software content. In addition, there are many tools available for hardware description language designs and a large number of circuit blocks available for re-use.
However, hardware description languages are not well-suited for testbench generation and testing. Additionally, hardware description languages are not designed with the intent of writing system models. Thus, hardware description languages are not a good fit for hardware/software co-design or for modeling an entire system that is composed of both hardware and software.
Object-oriented languages, on the other hand, have greater expressive power, e.g., classes, inheritance, etc., and are not aimed only at hardware implementation. A system-on-chip (SoC) design may require a number of “views”, such as a functional view, an architectural view, a verification view, a software implementation view, and a hardware implementation view. Object-oriented languages work for all of these views and are already being used for architectural definitions. Moreover, as the complexity and size of circuit designs increase, designers will likely move towards describing their designs at higher and higher levels of abstraction in order to enable faster simulation and hardware/software co-description and co-simulation.
Unfortunately, due to the fact that the use of object-oriented languages in modeling of circuit designs is still in its early stages, tool support for object-oriented language designs is weak. Additionally, more circuit designers are familiar with hardware description languages than with object-oriented languages.
Given the advantages and disadvantages of each type of programming language and the current trend of re-using design blocks created in earlier circuit designs to increase design speed and efficiency, circuit designs may comprise components written in both hardware description and object-oriented languages. Thus, there is a need for a method and system that would allow hardware description languages and object-oriented languages to be seamlessly integrated in one design.
Currently, connectivity between hardware description languages and object-oriented languages is provided via a basic application programming interface (API), in which standard call interfaces are used by programmers to allow a hardware description language based design to interact with an object-oriented language component. One drawback of this approach is that a designer is required to specifically know and recognize the proper API calls that must be made to implement connectivity. Other drawbacks of the API approach include: simulation speed limitations, difficulty in debugging, and no allowance for free mixing and replacement of object-oriented language and hardware description language design blocks.
In addition, the API approach does not provide seamless integration of hardware description language (HDL) and object-oriented language (OOL) in one design. Specifically, designers in a hardware description language modeling environment would not have the same level of access to OOL modules as HDL modules. For example, a designer would not be able to browse the source code for the object-oriented language block, step through it, or set break-points in it. An object-oriented module in an HDL modeling environment is essentially a black box, i.e., a designer is not able to look into the box. The same is true the other way around, i.e., an HDL module in an object-oriented language modeling environment would be unobservable from the outside.
The present invention provides a method and system for simulation of mixed-language circuit designs. In one embodiment, a simulator is configured to natively manipulate an object-oriented language module within a hardware description language based design. In another embodiment, a simulator is configured to natively manipulate a hardware description language module within an object-oriented language based design. In a further embodiment, an object-oriented language module is natively instantiated within a hardware description language based design. In a still further embodiment, a hardware description language module is natively instantiated within an object-oriented language based design.
Further details of aspects, objects, and advantages of the invention are described below in the detailed description, drawings, and claims. Both the foregoing general description and the following detailed description are exemplary and explanatory, and are not intended to be limiting as to the scope of the invention.